Development of a speech-based interface for most computer applications requires a grammar developer to define the phrases that a user may utter during his/her interactions with the computer application. These phrases are expressed in a grammar file, which is fed to a speech recognition component of the speech recognition system when the application is active. The constituent elements of the grammar file are called grammar rules. Grammar files are commonly expressed in a form like Backus-Naur Form (BNF) or the Java Speech Grammar Format (JSGF). An example grammar file (using a simplified syntax close to JSGF) is shown below:    public <Meeting>=Schedule a meeting on <Day>with <Friend>    <Day>=Tuesday |Thursday    <Friend>=Fred |Jack
This grammar file describes the following phrases:    Schedule a meeting on Tuesday with Fred    Schedule a meeting on Tuesday with Jack    Schedule a meeting on Thursday with Fred    Schedule a meeting on Thursday with Jack
These grammar rules use three non-terminal symbols (<Meeting>, <Day> and <Friend>) and nine terminal symbols (“Schedule”, “a”, “meeting”, “on”, “with”, “Tuesday”, “Thursday”, “Fred” and “Jack”).
Now suppose that the user of an application employing this grammar file uttered the following: “schedule an appointment on Thursday with Jack”. The collection of grammar rules shown above would not recognize the utterance since it fails to match any of the phrases listed above. Consequently, in order to provide a more natural interface to the user, the grammar developer is required to expand the grammar rules as shown below:    public <Meeting>=Schedule <Event> on <Day> with <Friend>    <Event>=an appointment¦a meeting    <Day>=Tuesday¦Thursday    <Friend>=Fred¦Jack
In the expansion described above, a terminal symbol group (“a meeting”) is selected from the grammar rule “public <Meeting>= . . . ”. Accordingly, “a meeting” is synonym expanded to generate a new grammar rule: “<Event>= . . . ” In this case, “an appointment” and “a meeting” are synonymous and are included in the new grammar rule. The modified version of the original grammar rule (“public <Meeting> . . . ”) is referred to as a synonym expanded grammar rule. In addition, the new grammar rule is referred to as a synonym rule, while the non-terminal in the synonym rule (“<Event>”) is referred to as the synonym rule non-terminal. This synonym expansion now enables the grammar file to recognize the user's utterance.
However, suppose that the user uttered the following: “Schedule a meeting with Jack on Thursday”. The grammar rules shown above would not recognize this utterance. Consequently, the grammar rules requires expansion as follows:    public <Meeting>=Schedule <Event> on <Day> with <Friend>    ¦Schedule <Event> with <Friend> on <Day>    <Event>=an appointment¦a meeting    <Day>=Tuesday¦Thursday    <Friend>=Fred¦Jack
In this example, groups of terminal and non-terminal components in the original rule can be reordered, while retaining the meaning of the original rule. To determine just which terminal or non-terminal components can be reordered, the grammar developer must analyze the language being used and study the way that users interact with the system in order to make changes accordingly. In this case, two prepositional phrases were reordered. The modified version of the original grammar rule (“public <Meeting> . . . ”) is referred to as a statement expanded grammar rule. Accordingly, the expansion process in this example is referred to as statement expansion. However, many other forms of expansion are possible.
Synonym and statement expansion of the initial grammar rule have resulted in quite a complex expanded grammar file, in spite of the fact that expansions were performed for only two simple cases. Nevertheless, current tools for grammar development force the application/grammar developer to address these issues manually. Unfortunately, this is a time consuming process. In addition, manual expansion is error prone and renders maintenance and debug of the resulting grammar files difficult. Therefore, there remains a need to overcome one or more of the limitations described above.